home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Replies to Views questions < prev    next >
Encoding:
Internet Message Format  |  1996-07-18  |  3.6 KB  |  [TEXT/ttxt]
  1. Subject:     Replies to Views questions
  2. Sent:        7/17/96 9:52 AM
  3. Received:    7/17/96 10:01 AM
  4. From:        Henri Lamiraux, lamiraux@apple.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. This is a bunch of replies to view questions.
  9.  
  10.  
  11.  
  12. ---------------------------------------------------------------------------
  13.  
  14. >Hello ODF types.
  15. >
  16. >Consider the following:
  17. >
  18. >FW_CPopupMenu* myProcesses = FW_NEW(FW_CPopupMenu, ( ev, this,
  19. >kValueTypeID, viewRect, kProcessMenuID, FW_CString(), 0, 1,
  20. >popupFixedWidth, FW_kHelvetica12 ) );
  21. >
  22. >Several questions:
  23. >1) there is no apparent way to construct pop-ups programmatically?
  24.  
  25. You can add or remove menu items with Mac calls.  See the section "Adding 
  26. and Removing Menu Items" in the engineering note "Using Controls". (the 
  27. popup must already exists, but
  28. you can leave 1 menu item that you delete later)
  29.  
  30. >2) passing a resource ID for a Macintosh Menu is not portable?
  31.  
  32. That's true. We used this implementation for ODF 1 for the sake of time.
  33. When ODF is ready on Windows we will have a portable Popup API.
  34.  
  35. >3) popupFixedWidth does NOT work; nothing shows, if I set it back to zero,
  36. >I get a dynamic width pop-up.  this a bug or mea culpa?
  37. >
  38.  
  39. I tried this with the Form sample (changing the popup variation field to 
  40. 1 in
  41. Views.fr) and it works.  
  42.  
  43. ---------------------------------------------------------------------------
  44.  
  45.  
  46. >A couple weeks ago someone posted a question about ordering subviews and I
  47. >haven't seen a response to it yet. I also need to draw my frame's subviews
  48. >in order of their view IDs instead of the order in which they were created.
  49. >(FW_CSuperView ignores the view IDs when drawing and simply traverses its
  50. >fSubViews list to draw each subview.) 
  51. >
  52. >Is there any way to prioritize the drawing of my subviews (preferably by
  53. >using view IDs)?. For example, it would be great if FW_CSuperView had a
  54. >SortSubViews() routine.
  55. >
  56. >Thanks,
  57. >Itrat.
  58.  
  59. Do you want to suggest to him to override FW_CSuperView::HandleDraw 
  60. in his class to change the ordering of subviews drawing?
  61.  
  62. Also, couldn't he create the subviews in the right order in the 1st place?
  63.  
  64. Implementing a SortSubViews method would be hard in ODF 1 because
  65. DeleteSubview has problems if I remember well.
  66.  
  67. ---------------------------------------------------------------------------
  68.  
  69.  
  70. >My part is based on ODF Container, and I want to implement my own scroller.
  71. >Currenlty a default scroller is read in from my View.fr resource. How do I
  72. >replace it with my own scroller. I looked at FW_CFrame::AdoptScroller and
  73. >it will not replace an existing scroller.
  74. >
  75. >-Neal
  76.  
  77. The only solution in ODF 1 is to implement his own scroller resource in 
  78. Views.fr
  79. (or remove the Container's scroller and create his owb by program)
  80. Once a scroller is created it's not possible to change it.
  81.  
  82. ---------------------------------------------------------------------------
  83.  
  84.  
  85. >Is there any (other than DoIdle()) for a CEditView to notify its receiver
  86. >that the content has changed?
  87. >
  88. >If it is not the case, it would be logical since it inherits of FW_MNotifier.
  89. >
  90. >Thanks,
  91. >
  92. >Paul.
  93.  
  94. I am sure there was a good reason to make FW_CEditView derive from 
  95. FW_MNotifier
  96. but I can't remember now!  (I may use this in Form)
  97. The general issue of adding a content model for edit views is something to
  98. address later.
  99.  
  100.  
  101. ........................................................................
  102.  Henri Lamiraux                                      lamiraux@apple.com
  103.  Apple Computer, Inc.                 OpenDoc(tm) Development Framework
  104. ........................................................................
  105.  
  106.  
  107.